1. Field of the Invention
The invention described herein relates to data networks, and in particular relates to packet processing.
2. Related Art
Any modem data network of appreciable size includes one or more devices whose job it is to relay information (e.g., ethernet packets) from one interface to another. Such devices include switches, routers, or any layer two bridge. Such devices will be referred to herein generically as forwarders. A forwarder will typically have multiple interfaces. This allows the forwarder to send and receive data over multiple connections. Each interface may have its own unique processing requirements. Different connections may require different communications media, different protocols and different data formats. Different connections may also require different operations such as cryptographic processing or error detection and correction. Moreover, the processing at different interfaces may be dependent on the options and features provided by specific equipment manufacturers or service providers.
An example of such a forwarder is illustrated in FIG. 1. Forwarder 110 has four different interfaces in this example. Interface 120 is an interface to an ethernet local area network (LAN). Interface 130 is a universal serial bus (USB) interface. Interface 140 represents a wireless 802.11 connection. Interface 150 represents a connection to a wide area network (WAN).
The processing required can vary from interface to interface for a variety of reasons. Processing may depend on the routing of data through the forwarder. For example, if data is entering forwarder 110 from LAN interface 120 for eventual transmission through WAN interface 150, certain operations may need to be performed on the data at interface 120. If, however, data enters forwarder 110 through LAN interface 120 and is bound for 802.11 interface 140, a different set of operations may be required at interface 120, or possibly the same set of operations in a different order. Specific processing at an interface may also vary based on the content of the data. A specific IP header, for example, may dictate a specific action. Specific data fields in the data packet may have to be manipulated, e.g. an address field or type of service bits.
Given the variety of processing that may be required at different interfaces, one solution might be to make all such processing available at all interfaces. A single generic interface module would then be available at every interface. This is inefficient for several reasons. Generally, not all of the processing is required for every circumstance. Some processing is never needed at a specific interface; other processing may be needed only conditionally, depending on the source and destination, on specific data fields, or on a specific system context, etc. Implementing a single generic interface software module therefore represents more logic than is necessary. Memory would be consumed for software that may not be needed. Software maintenance would also be unnecessarily complicated. Execution of a generic interface module would consume excessive CPU resources.
Moreover, implementation of a generic interface module could create management issues with respect to vendor proprietary information. Features may have to be built into the interface software module to accommodate one or more features offered by a specific vendor. Yet, given the proprietary nature of the resulting software, distribution of the software module would have to be controlled. This would necessitate multiple versions of the software module and the attendant configuration control problems.
What is needed, therefore, is a system and method for processing data at forwarder interfaces that is modular and flexible, and that incurs minimal processing overhead so that only the necessary processing logic is implemented for any given interface.